1. Field of the Invention
The present invention generally relates to data processing. More particularly, embodiments are provided for organizing performance data collected for a program being debugged.
2. Description of the Related Art
Inherent in any software development technique is the potential for introducing “bugs”. A bug will typically cause unexpected results during the execution of the program. Locating, analyzing, and correcting bugs in a computer program is a process known as “debugging.” Debugging of programs may be done either manually or interactively by a debugging system mediated by a computer system. Manual debugging of a program requires a programmer to manually trace the logic flow of the program and the contents of memory elements, e.g., registers and variables. In the interactive debugging of programs, the program is executed under the control of a monitor program (known as a “debugger”). The debugger may be located on and executed by the same computer system on which the program is executed or may be located on a different system from the one the program is executed on, in the case of a distributed debugger.
Conventional debuggers typically support various operations to assist a computer programmer. Each operation allows the programmer to examine the state of program registers and variables at a given point in the execution of a program. Typical operations supported by conventional debuggers include breakpoint operations, “step” functions, and “run to” operations.
A “breakpoint” is a point in the program where execution of the computer program is stopped so that the state of the program can be examined by a computer programmer. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a breakpoint is reached. The debugger then stops execution and displays the results of the computer program to the programmer for analysis.
The use of breakpoints is particularly useful in today's multithreaded environments. Threads present timing problems that can be very difficult to track down. Accordingly, today's debuggers allow users to set breakpoints, and once the breakpoint is hit the users can examine the position of each thread in an application to determine whether the thread is behaving as expected. However, such use of breakpoints only provides a snapshot of the current state of the program, and does not provide information as to why the current state has occurred.
Therefore, a need exists for a debugger which provides historical information about the execution of threads.